Service-oriented architectures have evolved to make available to service consumers (sometimes referred to herein as “clients”) typically via a public, discoverable, and standards-based interface, such as Web Services/SOAP, functionality traditionally provided by procedural and later object-oriented architectures via a tightly defined and often proprietary API. In distributed environments, such as network environments, prior to the development and deployment of service-oriented architecture some computing tasks were performed at clients by rich client-side applications and/or application frameworks, which were communicated with via a typically proprietary API by third party applications or other code running at the client. Such rich client applications and/or frameworks typically interacted with applications or other code executing at the client to determine what tasks the application or code required to be performed, gathered at the client the data required to perform those tasks, and communicated with a remote server on behalf of such application or code in an optimized manner to complete the tasks. In such an environment, the gathering of information to perform tasks and the work required to perform those tasks were completed by invoking procedures, business logic, and/or methods of software objects, as required, all orchestrated by logic at the server side and/or the rich client application and/or framework. Some functionality provided by software developed and written originally as procedural or object-oriented applications have been made available via service-oriented protocols, but typically software owners have merely recast an API conceived for the procedural or object-oriented paradigm as a Web Services or similar interface, which approach can result in inefficiencies, such as multiple round trip network interactions to accomplish a single task, or delays resulting from unresolved dependencies, etc.